昨天提了軟體開發生命週期，有哪些關鍵測試類型，但為什麼做了相關系統測試後，系統還是被打爆了？

原因是：防禦不能只靠事後掃描與測試，必須在需求與設計階段就導入 Threat Modeling（威脅建模），從攻擊者角度審視系統架構。這也呼應了CRISC 領域三：風險回應（Risk Response），在系統變更或開發初期即落實 Risk Avoidance / Mitigation。

什麼是威脅建模(Threat Modeling)？它是一種結構化、主動式的資訊安全風險評估方法。它的核心概念是：「在系統還沒被攻擊、甚至是程式碼還沒寫出來之前，先站在攻擊者的角度，找出系統架構與設計上的潛在漏洞。」

依Adam Shostack所提，威脅建模的思考框架如下，可讓相關人員較快建立邏輯架構：

• 我們正在建構什麼？（What are we building?）：繪製資料流圖（DFD）、釐清系統邊界與信任邊界（Trust Boundary）。

• 什麼地方會出錯？（What can go wrong?）：套用威脅模型（如 STRIDE）識別潛在威脅。

• 我們該如何處理？（What are we going to do about it?）：制定控制措施、修補漏洞或進行風險轉移/承受。

• 我們做得夠好嗎？（Did we do a good enough job?）：事後複盤與持續滾動修正。

而實務上常用的工具為STRIDE模型，該模型可轉化為軟體開發團與風險管理團隊者「聽得懂」的語言。

STRIDE 模型將資安威脅細分為六大類，協助團隊在系統架構設計階段對應安全屬性與防禦對策：

S (Spoofing 冒充)：偽造合法身分進行非法存取。

T (Tampering 竄改)：未經授權修改資料或程式碼，破壞完整性。

R (Repudiation 否認)：使用者否認曾進行某項操作，因缺乏不可否認的稽核紀錄。

I (Information Disclosure 資訊洩漏)：機密資料遭受未授權讀取或外洩。

D (Denial of Service 阻斷服務)：癱瘓系統資源，導致合法使用者無法使用服務。

E (Elevation of Privilege 權限提升)：低權限帳號透過漏洞取得管理者或高階權限。

以上，即是今天重要的 Threat Modeling（威脅建模）議題分享。